Dynamic memory management

ABSTRACT

The present invention relates to a memory management system for allocating memory in a memory space according to amounts of memory requested by a client, said memory space comprises a number of equally sized containers, and at least some of said containers comprise a number of equally sized sub containers. The system comprises means for generating a memory block, wherein the size of said memory block is selected between a number of predefined sizes, where the selected size is at least equal to said amount of memory requested by the client. The system also comprises means for allocating memory for said memory block in a container, the container being the smallest container having a size being at least twice the size of the memory block.

The present invention relates to a memory management system forallocating memory in a memory space according to amounts of memoryrequested by a client. The invention also relates to a method ofallocating memory in a memory space. Further, the invention relates toan operating system embodied on a computer readable medium comprising amethod of managing memory. The invention also relates to a computerreadable medium, comprising an algorithm for performing a method ofmanaging memory, and to an embedded real-time software system comprisinga method of managing memory. Finally, the invention also relates to afile system comprising a method of managing memory.

Computer programs are typically algorithms that manipulate data tocompute a result. A block of memory to store data must first beallocated before the data can be manipulated. When the data is no longerneeded, the block of memory is deallocated or freed. Allocation anddeallocation of the block of memory are commonly referred to as memorymanagement.

Memory management is performed by an allocator administrating the memoryby keeping track of memory blocks that are in use or that are free, andby doing this as quickly as possible. The ideal allocator allocates andfrees blocks of memory wasting no space and time.

A conventional allocator cannot compact memory and once it has decidedwhich block of memory to allocate, it cannot change that decision.Consequently, the block of memory must be regarded as inviolable untilthe program that requested the block chooses to free it. In fact, anallocator can only deal with memory that is free. A conventionalallocator is therefore an “online” algorithm that must respond torequests immediately, and its decisions are irrevocable.

For the case of a conventional allocator, it has been proven that forany possible allocation algorithm, there will always be the possibilitythat some application program will allocate and deallocate blocks in away that defeats the allocator's strategy, and forces it into severefragmentation. When some of the characteristics (with regard to memoryrequests) of the memory users are known, the memory allocator can be“tuned” for these specific requests. This tuning can decreasefragmentation problems. Also, a combination of dynamic and staticallocation and the use of certain algorithms can reduce fragmentation,unfortunately introducing memory overhead and CPU-time consumption.

Dynamic memory management introduces four new issues in addition tostatic memory usage, namely:

-   -   External fragmentation    -   Internal fragmentation    -   Memory overhead (table fragmentation)    -   Real time Performance issues

Internal fragmentation can be accepted as part of a strategy to preventexternal fragmentation. E.g. in embedded software, externalfragmentation is not allowed because this may get worse over time,virtually reducing the amount of memory.

Memory overhead is often caused by bookkeeping. Tables are often usedfor this and therefore it is often referred to as table fragmentation.These tables can for instance be static lists, containing free blocks,or lookup tables. Memory overhead in the form of tables is verypredictable because it is static.

An allocator must respond as fast as possible to requests of the memoryusers. The number of allocations and deletions can be very large in forexample a C++ environment and therefore, it is desirable that thealgorithms that are being used are very fast. In general, bad real timeallocation performance is due to searching of specific free lists tofind a suitable block of memory. In the case of freeing a block ofmemory, the time is generally being used for looking for the identity(e.g. size) of the block, since for a conventional allocator, only apointer is passed for deletion.

A trade-off has to be made between these four issues of dynamic memorymanagement. For instance low internal- and external fragmentation can beachieved at the expense of worse timing performance and visa versa. Anexample of this is a compacting memory allocator where (in theory) nofragmentation occurs, but the algorithms used are more (time) complex.Conversely, an (almost) absence of a memory allocation strategy (i.e. bylaying down blocks consecutively in the memory) brings about good realtime performance, but very bad fragmentation figures.

The most straightforward strategy is a sequential fit. There are severalimplementations of this strategy namely first, next, best and worst fit.Because blocks are not rounded to a predefined value, no memory loss dueto rounding, also called “internal fragmentation”, is introduced.Another advantage of this method is its simplicity. However, severefragmentation can occur and the fact that the accompanying free list issearched to find a suitable block is a quite time consuming operation.

Another strategy is to use the “segregated free lists”. Twoimplementations are known, namely quick- and fast fit. This strategyalso suffers from external fragmentation and because all sizes cannot besupported, rounding loss is introduced as well. However, this method isvery fast because no free lists have to be searched.

Another very frequently used strategy is the buddy system. For thisstrategy there are also several implementations, namely the binary, theFibonacci, the weighted and the double buddy system. The advantages ofthe binary buddy system are fast coalescing of (buddy-) blocks andsimple administration. The main drawback of this method is the poorutilization of memory because the rounding is very coarse, introducing alot of internal fragmentation. The binary buddy system suffers fromexternal fragmentation as well. Also, a header per block is necessaryfor management purposes. The Fibonacci buddy system more or less has thesame drawbacks as the binary system. However, internal fragmentation isreduced because the values of the Fibonacci series do not grow as fastas values that are a power of two. An additional disadvantage is thefact that calculation of a buddy is more expensive. Another possibledisadvantage of Fibonacci buddies is that when a block is split tosatisfy a request for a particular size, the remaining block is of adifferent size, which is less likely to be useful if the programallocates many objects of the same size. The weighted and double buddysystems have the same drawbacks as the binary buddy system, but too havethe advantage of having a smaller intra-block difference.

A totally different dynamic memory management approach is the compactinghandle based strategy. There is no question of internal fragmentationbecause blocks are not rounded. Emerging external fragmentation issolved during runtime by means of compaction. However, because of thiscompaction, no real-time predictable performance can be guaranteed.Also, a level of indirection is introduced. Due to this indirectionmemory overhead is introduced as well.

Another method of managing memory is by subdividing the memory spaceinto smaller parts, all of the same size, called containers. Within acontainer, memory blocks requested by a client, are allocated. Here eachcontainer holds blocks of only one particular size. The advantages ofthis approach are firstly that allocation and deallocation are fast;internal fragmentation is very low and secondly that no externalfragmentation is introduced due to the equally sized containers. As aresult, a very reliable way of dynamic memory management for embeddedreal-time systems is offered. The method, however, also has a bigdrawback: there is only one container size available that should bechosen such that it is optimal for efficiently holding blocks ofdifferent sizes (within one container all blocks have same size). If therange of block sizes is wide, optimisation is impossible. As acircumvention of the drawbacks two different container sizes areproposed for a specific product realization: one to hold small blocks(<1 Kb) and one to hold large blocks (>1 Kb, <64 Kb). Next, if blocksizes vary considerably, then the two container sizes are not enough toachieve efficient memory utilization. Finally, the solution alsorequires the complete memory address space to be subdivided in twoparts: one part holding small containers and another part holding largecontainers, see FIG. 1. As a result, the solution only works if allrequested block sizes are known in advance.

It is an object of the present invention to perform memory allocation inan improved way.

This is obtained by a memory management system for allocating memory ina memory space according to amounts of memory requested by a client. Thememory space comprises a number of equally sized containers, and atleast some of the containers comprise a number of equally sized subcontainers. The system further comprises means for generating a memoryblock, wherein the size of said memory block is selected between anumber of predefined sizes, where the selected size is at least equal tosaid amount of memory requested by the client. Further, the systemcomprises means for allocating memory for said memory block in acontainer, the container being the smallest container having a sizebeing at least twice the size of the memory block.

The memory allocation proposed by the memory management system accordingto the present invention can be optimized by tuning the sizes of thecontainers and the number of container sizes. Furthermore, themulti-level, nested container principle proposed by this inventionaccepts a very wide range of block sizes, hence will work directly inall practically situations without a-priori knowledge of block sizes.Moreover, the number of container levels and sizes can be configureddynamically at start-up by first requesting the available memory spaceand subdividing it a number of times. Finally, having a very big, toplevel container size will have little influence on the allocationbehaviour of small blocks, since their allocation behaviour ispredominantly determined by the smallest defined container size. At anycontainer nesting level, containers have an equal size. The advantage isthat repetitive allocation and de-allocation of any container or subcontainer will not introduce fragmentation of the memory space, becauseany hole in the memory space caused by de-allocation of one or severalcontainers is exactly large enough to fit exactly the same number of anynewly allocated containers at this level in the container hierarchy,without loss of memory space. The size of containers and blocks can bechosen such that memory utilisation is maximised. By making a memoryallocation profile for an embedded system, optimisation of container andblock sizes is possible.

In an embodiment, the sub container is placed in a container having asize being at least twice as small as the container.

The goal of introducing sub-containers is to increase memory utilizationefficiency. Namely, memory requests of (rounded to) a particularblock-size should fill at least a complete container of a particularsize, leaving very little space to spare compared to the space occupiedby the blocks in the container. If, for a particular block size, thereis no single container that is completely filled, while there are asignificant number of blocks of this particular size allocated insidethis container, then the container size is apparently chosen too big.This is undesirable because much space in the container is not used. Inthis case, it is useful to introduce a smaller container. It is,however, of no use when this smaller container only fits one time insidethe current container because the remaining space cannot be reusedanymore by another container, since at any nesting level, containershave equal size. Furthermore, since each container typically has aheader holding some information about its contents, it is more efficientto have more than 2 sub-containers per container. The same holds for thenumber of blocks in a container. As mentioned before, the efficiency isheavily determined by the filling of containers by blocks of aparticular size; hence containers should not be too large either.

In a specific embodiment, a container is dedicated for equally sizedmemory blocks. Thereby memory blocks within a container all have equalsize assuring that repetitive allocation and de-allocation of blockswithin a container do not give rise to fragmentation within thecontainer. It is guaranteed that any space freed-up in a container willbe exactly large enough to fit a new allocation request. Next,de-allocation is fast, because for a particular memory address, only theassociated container needs to be found, which then has information inits header about the size of the blocks it contains. The length of thissearch is determined by the container nesting level, which is verylimited (typically smaller than 4) even for a very large range of blocksizes (e.g. ranging from 32 bytes to 200 Kbytes).

In an embodiment, the size of the largest container has been selected insuch a way that when filling the memory space with said largestcontainers the remaining area, being smaller than said largestcontainer, has a size which is significantly smaller than said largestcontainer. By subdividing the memory space into containers, one shouldchoose the container size such that the remaining space—which is toosmall to fit another container of this size—is as small as possible. Ifthis remaining space is nearly as big as a full container, this isclearly not very efficient. Note, however, that this is not alwaysnecessarily true if the largest container size is very small compared tothe full memory space, e.g. maximum container size is 65306 bytesfitting 256 times a memory space of 16 MB and leaving 58880 bytes unused(0.3% loss).

In another embodiment, the size of the sub container being placed in acontainer has been selected in such a way that when filling thecontainer with said sub containers the remaining area being smaller thansaid sub container has a size, which is significantly smaller than saidsub container. When choosing particular container sizes, including somereservation for headers, it is not always possible to choose the size ofsub-containers such that a multiple of this size fits exactly into ahigher-level container size. This is no problem whatsoever. However,when the sizes of sub-containers are chosen such that some space in thehigher-level container is just too small to fit another sub-container,the space of nearly a full sub-container is lost. Clearly, it is notvery efficient if only a few sub-containers can fit into a largercontainer.

The invention also relates to a method of allocating memory in a memoryspace according to amounts of memory requested by a client, said memoryspace comprises a number of equally sized containers, and at least someof said containers comprise a number of equally sized sub containers,said method comprises the steps of:

-   -   generating a memory block, wherein the size of said memory block        is selected between a number of predefined sizes, where the        selected size is at least equal to said amount of memory        requested by the client,    -   allocating memory for said memory block in a container, the        container being the smallest container having a size being at        least twice the size of the memory block.

The invention also relates to an operating system embodied on a computerreadable medium, the operating system comprising a method of managingmemory according to the above.

The invention also relates to a computer readable medium comprising amethod of managing memory according to the above.

The invention also relates to an embedded real-time software systemcomprising a method of managing memory according to the above. Thesystem is very well suited in real-time environments, because of thefast allocation and de-allocation strategy and the performancepredictability.

The invention also relates to a file system comprising a method ofmanaging memory according to the above. A file system can map requestsof different sizes to different partitions on a disk to optimise theperformance of read/write accesses. This is useful for streaming datasuch as audio and video that must be recorded and played back to/from adisk.

In the following preferred embodiments of the invention will bedescribed referring to the figures, where

FIG. 1 illustrates an example of a memory space according to the presentinvention,

FIG. 2 illustrates a simple example illustrated where 2 sizes of memoryblocks B₁, B₂ are placed in the containers of the memory spaceillustrated by FIG. 1,

FIG. 3 shows an example of the global functional structure of anallocator with two container-sizes wherein the smaller container is asub container of the larger container,

FIG. 4 illustrates an embodiment of a memory management system accordingto the invention.

The current invention describes the memory space that is available fordynamic allocation by clients as a hierarchy of stacked containers. Inthis approach, all the available memory space is subdivided in equallysized containers. Each container then either holds blocks of a specificsize as requested by a client or multiple sub containers of a smallersize. In a preferred embodiment and in order not to waste memory space,the size of a large container comprising sub containers should have asize being a multiple of the smaller sized sub containers.

The size of allocated blocks is determined by a client and can thereforenot be chosen to optimally fit multiple times in a container of aparticular size. However, it can be shown that highly memory efficientallocation can be achieved if the size of blocks is small compared tothe container in which they are contained.

A specific method of describing the memory space according to thepresent invention is by the following:

The total allocable memory space is denoted by M, then a set ofcontainers C_(i) i=0, 1, 2, . . , is chosen such that:n _(i) εN,n _(i)≧2,i=0,1,2,3, . . . ,n ₀ C ₀+Δ₀ =M,Δ ₀ <<C ₀,n _(i+1) C _(i+1)+Δ_(i+1) =C _(i),Δ_(i+1) <<C _(i+1),

The formulas express that in the range of container sizes, a smaller subcontainer should at least fit two times in a larger container. Also,possibly wasted space Δ_(i) should be significantly smaller than thesize of the smaller sub container.

The memory blocks being allocated in the memory space should be placedin the containers according to the following:

Memory blocks of k different sizes B_(k), k=0, 1,2, . . . are fittedinto a container C_(i) if,l _(k) εN,l _(k)≧2, k=0,1,2,3, . . . ,B_(k+1)<B_(k),C_(i+1)<2B_(k),l _(k) B _(k)+δ_(k) =C _(i),δ_(k) <<B _(k)

The same is expressed for blocks fitting into containers. Moreover, ablock will only be put in a specific container if it is too big to fitat least two times in a smaller sized container, and if the wasted spaceδ_(k) in the container is significantly smaller than the size of thisblock.

As soon as a client requests an amount of memory corresponding to theallocation of a block B_(k), it is checked in which container it shouldbe placed.

In FIG. 1, an example of a memory space according to the presentinvention is illustrated. The memory space 101 could either be acontiguous piece of memory or it could comprise contiguous chunks ofmemory as illustrated by 103 and 105. The memory space is then dividedinto a number of equally sized containers 107, where the size C₀ of thecontainers should be chosen in such a way that wasted space Δ₀ issignificantly smaller than the size of the containers 107. Some of thecontainers are then divided into a number of equally sized subcontainers 109, where the size C₁ of the sub containers should be chosenin such a way that wasted space Δ₁ is significantly smaller than thesize of the sub containers.

In FIG. 2, a simple example is illustrated where memory blocks of sizesB₁, B₂ are placed in the containers of the memory space illustrated byFIG. 1. The smallest blocks of size B₂ are placed in the containers 109of size C₁, while the larger blocks B₁ will be placed in the containers107 of size C₀.

FIG. 3 shows an example of the global functional structure of anallocator with two container-sizes wherein the smaller container 301 isa sub container of the larger container 303. When an amount of memory isrequested 305, the amount is checked in 307 and may be pre-rounded insuch a way that subsequent rounding to a particular block size can bedone faster. The first step in the allocation process is thedetermination of the appropriate block size to which this request mustbe rounded. In 309 determination of the appropriate block size isperformed by means of a look-up table, a hash table or any other methodthat implements efficient selection of a particular block size for agiven allocation request. Next in 311, the appropriate container size isdetermined for the given block size. Also, this can be done using alook-up table, a hash table or a simple algorithm that uses the criteriadescribed above i.e., if the requested block size is at least twice assmall as a particular container size, the block of memory will befetched from an available container of this size, otherwise the block istaken from the larger container. Requests greater than the largestcontainer size are not supported and result in an exception.

When the first request takes place and no container has been allocatedyet, a new container of the largest size will be allocated and will beadded to the list of “free” containers of this size. This action alsooccurs if all previously allocated containers of this size are filled orreserved for a different block size. The allocation of new containers onrequest can be considered as incremental formatting of the memory space.

Alternatively, it is also possible first to subdivide the completememory space into the “largest” container size C₀ and put pointers tothe starting positions of these in a “free container list” of size C₀.Once a container is used to serve an allocation request, it is removedfrom its corresponding free list. If a container of a different sizemust be selected, then the free list of containers of that size is usedto fetch a free container. If this free list is empty, then a freecontainer of a larger size is selected, removed from its free list andsubdivided into free containers of the next smaller size. All, exceptone, of these smaller containers are then subsequently put in the freecontainer list of that particular container size. Note that this can bedone incrementally with each next request, such that predictableperformance can be guaranteed. One of these smaller containers will nowbe used to serve the block request. If this container is still too big,it will be subdivided again and again, similar to what is describedabove.

Finally, when a container of the appropriate size has been found andallocated, it is (virtually) subdivided into pieces, just big enough tohold an individual block. Now a free list will be created for this blocksize. The free list does not need to contain all start positions of all“free” blocks in the container. These can also be added incrementallyduring allocation/de-allocation sequences, just as can be done for“free” container lists. If for a particular block size any free listexists, then no container allocation and formatting is required.

FIG. 3 shows the situation when just one container size 313 is stillempty, hence only for this container size there is still a freecontainer list 315 holding one item. All other free lists for freecontainers of other sizes are empty, they no longer exist. Still, thereare a number of free lists 307 for blocks of different sizes. In anembodiment, as illustrated in FIG. 3, empty blocks within a containere.g. 317 are linked. In this way, a certain container is completely usedup before another container is applied and empty blocks can easily beidentified.

FIG. 4 illustrates an embodiment of a memory management system 400 forallocating memory in a memory space according the above described. Thesystem comprises a microprocessor 401 connected to a memory module 403,comprising the memory space, via a communication bus 405. Themicroprocessor then performs the memory allocation in the memory spaceaccording to the allocation algorithm stored in the memory module 403.

1. A memory management system for allocating memory in a memory spaceaccording to amounts of memory requested by a client, said memory spacecomprises a number of equally sized containers, and at least some ofsaid containers comprise a number of equally sized sub containers, saidsystem further comprises: means for generating a memory block, whereinthe size of said memory block is selected between a number of predefinedsizes, where the selected size is at least equal to said amount ofmemory requested by the client, means for allocating memory for saidmemory block in a container, the container being the smallest containerhaving a size being at least twice the size of the memory block.
 2. Amemory management system according to claim 1, wherein the sub containerbeing placed in a container has a size being at least twice as small assaid container.
 3. A memory management system according to claim 1,wherein a container is dedicated for equally sized memory blocks.
 4. Amemory management system according to claim 1, wherein the size of thelargest container has been selected in such a way that when filling thememory space with the largest containers, the remaining area beingsmaller than said largest container has a size which is significantlysmaller than said largest container.
 5. A memory management systemaccording to claim 1, wherein the size of the sub container being placedin a container has been selected in such a way that when filling thecontainer with said sub containers, the remaining area being smallerthan said sub container has a size which is significantly smaller thansaid sub container.
 6. A method of allocating memory in a memory spaceaccording to the amounts of memory requested by a client, said memoryspace comprises a number of equally sized containers, and at least someof said containers comprise a number of equally sized sub containers,said method comprises the steps of: generating a memory block, whereinthe size of said memory block is selected between a number of predefinedsizes, where the selected size is at least equal to said amount ofmemory requested by the client, allocating memory for said memory blockin a container, the container being the smallest container having a sizebeing at least twice the size of the memory block.
 7. A method accordingto claim 6, wherein the sub container being placed in a container has asize being at least twice as small as said container.
 8. A methodaccording to claim 6, wherein a container is dedicated for equally sizedmemory blocks.
 9. A method according to claim 6, wherein the size of thelargest container is selected in such a way that when filling the memoryspace with said largest containers, the remaining area being smallerthan said largest container has a size which is significantly smallerthan said largest container.
 10. A method according to claim 6, whereinthe size of the sub container being placed in a container is selected insuch a way that when filling the container with said sub containers, theremaining area being smaller than said sub container has a size which issignificantly smaller than said sub container.
 11. An operating systemembodied on a computer readable medium, the operating system comprisinga method of managing memory according to claim
 1. 12. A computerreadable medium comprising an algorithm for performing a method ofmanaging memory according to claim
 1. 13. An embedded real-time softwaresystem the real-time software system comprising a method of managingmemory according to claim
 1. 14. A file system comprising a method ofmanaging memory according to claim 1.